Some JDBC connection pools create a dynamic reflective Proxy wrapper
around connections in the pool, plus the generated statements and the
result sets those statements create, with the proxies allowing for
methods calls to be intercepted by the connection pool for the purposes
of returning items to the pool when they're released rather than
destroying the underlying database connection. Tomcat's JDBC pool
implementation does not correctly wrap the full chain of objects,
meaning the raw Statement can be retrieved from a ResultSet rather than
returning the proxied statement. This results in the ResourceRegistry
cache attempting to store both the proxied Statement and the non-proxied
Statement in its cache, but encountering an exception when the HashMap
encounters two entries with the same HashCode and then attempts to
differentiate them with an `equals` call which Tomcat's wrapper expects
both instances to be proxied connections. To overcome this issue in
Tomcat, as well as any other pool implementation which may use Proxy
classes but leak the un-proxied entries, the original PreparedStatement
used to create the ResultSet is being passed into the
GeneratedValuesHelper for passing into the ResourceRegistry, rather than
the GeneratedValues helper attempting to extract the Statement from the
ResultSet.